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1 Background 

This is a final report on the "Cooperation among Theorem Trovers" project, which supports 
NASA's PECSEE (Persistent Cognizant Software Engineering Environment ) effort and com- 
plements the Kestrel Institute project "Inference System Integration via Logic Morphisms”. 
The ultimate purpose of the project is to develop a superior logical inference mechanism by 
combining the diverse abilities of multiple cooperating theorem provers. 

In many years of research, a number of powerful theorem-proving systems have arisen 
with differing capabilities and strengths. Resolution theorem provers (such as Kestrel's 
KITP or SRI's SNARK) deal with first-order logic with equality but not the principle of 
mathematical induction. The Boyer- Moore theorem p rover excels at proof by induction but 
cannot deal with full first-order logic. Both are highly automated but cannot accept user 
guidance easily. The PYS system (from SRI) in only automatic within decidable theories, but 
it has well-designed interactive capabilities: furthermore, it includes higher-order logic, not 
just first-order logic. The XuPRL system from Cornell Lniversity and the STeP system from 
Stanford University have facilities for constructive logic and temporal logic, respectively— 
both are interactive. 

It is often susgested — for example, in the anonymous QED Manifesto that ue should 

pool the resources of all these theorem provers into a single system, so that the strengths of 

one can compensate for the weaknesses of others, and so that effort will not be duplicated. 

However, there is no straightforward way of doing this, because each system relies on its own 

language and losic for its success. Thus. SNARK uses ordinary first-order logic with equality. 

PYS uses higher-order logic, and XuPRL uses constructive logic. 

The purpose of this project, and the companion project at Kestrel, has been to use the 

category-theoretic notion of logic morphism to combine systems with different logics and 

lamma^es. Kestrel’s SPECWARE svstem has been the vehicle for the implementation. 

© © 


2 SPECWARE 

Kestrel's SPECWARE is a category-theory-based software development environment. It ex- 
ploits categorv theorv to capture two fundamental notions: the refinement of specifications 
into code and the composition of software components. 

The fundamental objects of SPECWARE are specifications and the morphisms between 
them. SPECWARE uses the word "specification " in an uncommonly general way it includes 
theories and code as well as high-level descriptions of software. A morphism is a kind of 
mapping between specifications that indicates how one specification — the source — can be 
viewed as a subtheorv of another specification the target. A moiphism identifies each 
symbol of the source theory with a corresponding symbol in the target theory, in such a 
way that, the theorems of the source theory are mapped into theorems of the target theory. 
For SPECWARE to verify a morphism, it must prove that each axiom of the source theory is 
mapped into a theorem of the target theory. For this purpose, it contains its own theorem 
prover. KITP. 

To capture the notion of software refinement. SPECWARE uses the' category-theoretic 
concept of an interpretation. The SPECWARE notion of software composition is based on the 
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category-theoretic concept of a colimit. Both of these concepts are based on morphisms. For 
instance, a refinement is a morphism from a source theory into a mediator — not the target 
theory itself but an extension of the target in which new concepts have been defined. 

The essence of the Kestrel approach to combining two theorem provers is to build a 
refinement between their logical systems. However, in an ordinary refinement, both theories 
must have the same logical inference system, while different theorem provers are based on 
different logical systems. To smooth over these anomalies. Kestrel employs the notion of an 
inter-logic refinement, based on Meseguer’s concept of a logic morphism. 

Although Kestrel has formulated the principles of the inter-logic refinement. SPECWARE 
does not support this refinement in the way it supports the single-logic refinement. In 
support of this project, a new inter-logic morphism must be built between SPECWARE and 
each theorem prover to be connected. The first system to be connected (after Kestrel's own 
KITP ) has been SRI's S.NARK. Since the inter-logic morphism is not yet implemented, this 
has been done using primitives of the underlying implementation language. REFINE. This 
experiment will guide future development of the implementation of the inter-logic morphism 
within SPECWARE. 


3 SNARK 

SnaRK is SRI's theorem prover for first-order logic with equality, based on resolution, 
paramodulation. and term-rewriting inference rules. S.NARK has built-in associative and 
commutative unification algorithms, and facilities for inserting new unification algorithms— 
this means SNARK can deal efficiently with theories with commutative or associative oper- 
ators. It also has a built-in decision procedure for temporal reasoning, using the temporal 
primitives of James Allen. S.NARK has a sort structure, and its unification algorithms are 
cognizant of that structure so that terms of mismatched sorts cannot be unified. SNARK 
strategies can easily be altered or replaced by the S.NARK user. In particular, its agenda- 
ordering strategy can be changed by providing a new LISP function, and SNARK can follow 
a user-supplied symbol ordering so that "bad" symbols will tend to be replaced by "good 
symbols. 

SNARK has been employed by NASA as the fundamental reasoning component of the 
Amphion system. It has been augmented by NASA in several ways: in particular, in Meta- 
Amphion. facilities have been introduced for identifying .sets of axioms that can be removed 
and replaced by decision procedures, with dramatic improvements of efficiency. 

Part of the reason for wanting to combine SNARK and SPECWARE is to use SPECWARE s 
notion of morphism to formalize the search for a decidable subtheory. If SPECWARE is given 
a library of decidable theories, we can look for morphisms from any of those theories into 
the theory at hand — the image of a decidable theory will be a decidable subtheory. 

4 The SPEC WARE-SN ARK interface 

SRI has collaborated with the Kestrel Institute in building a SPEC WA R E-S N A R K interface. 
SRI's part of the effort has consisted of improving SNARK s own interface, working with 
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Kestrel personnel on the design of the SPECWARE-SNARK interface, and selecting default 
values for SNARK parameters when it is invoked by SPECWA RE. Our ideal has been that the 
theorem prover should be invisible to the naive user, but that the knowledgeable user should 
have full access to SNARKs capabilities. 

For instance, the initial parameter settings cause the search for a proof, and the proof 
itself, to be invisible to the user, who simply receives a report that the theorems have 
been proved and the morphism verified. The selection of defaults varies according to the 
application: for instance, in normal theorem proving, hyperresolution is employed, but if a 
witness is to be extracted from the proof, binary resolution is invoked instead. This is because 
hyperresolution is more effective in general, but is incompatible with witness-finding. 

Should the proof fail, the user may change the settings to exhibit the failed proof attempt 
and, if necessary, alter the inference rules, parameter settings, or strategy. But this requires 
a more educated user. 


5 A Verification Example 

Let us examine an example of a verification problem. We are given the specification for a 
bit. 

spec BIT is 
sort Bit 
op bit-0 : Bit 
op bit-1 : Bit 

axiom (not (equal bit-0 bit-1)) 

axiom (fa (x : Bit) (or (equal x bit-0) (equal x bit-1))) 
constructors {bit-0, bit-1} construct BIT 


•/, 

op bit-plus : Bit, Bit -> Bit 
definition of bit-plus : Bit, Bit -> Bit is 
axiom (equal (bit-plus bit-0 bit-0) bit-0) 
axiom (equal (bit-plus bit-0 bit-1) bit-1) 
axiom (equal (bit-plus bit-1 bit-0) bit-1) 
axiom (equal (bit-plus bit-1 bit-1) bit-0) 
end-definition 


Y. 

op bit-carry : Bit, Bit -> Bit 
definition of bit-carry is 

axiom (equal (bit-carry bit-0 bit-0) bit-0) 
axiom (equal (bit-carry bit-0 bit-1) bit-0) 
axiom (equal (bit-carry bit-1 bit-0) bit-0) 

axiom (equal (bit-carry bit-1 bit-1) bit-l) 
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end-definition 


op bit-and : Bit, Bit -> Bit 
definition of bit-and is 


axiom (equal (bit-and bit-0 bit-0) 

axiom (equal (bit-and bit-0 bit-1) 

axiom (equal (bit-and bit-1 bit-0) 

axiom (equal (bit-and bit-1 bit-1) 

end-definition 


bit-0) 

bit-0) 

bit-0) 

bit-1) 


theorem bit-and-carry is (equal (bit-and bl b2) (bit-carry bl b2)) 

theorem bit-and-carry-iff is 

(iff (equal (bit-and bl b2) bit-1) 

(equal (bit-carry bl b2) bit-1)) 

theorem bit-and is 

(iff (equal (bit-and bl b2) bit-1) 

(and (equal bl bit-1) (equal b2 bit-1))) 

<Some operations and theorems omitted. > 
end-spec 

In other words, there are two bit constants, bit-0 and bit-1, each of sort Bit. The first 
axiom asserts that these two bits are distinct. The second asserts that every bit is either 
bit-0 or bit-1. The constructors statement amounts to an induction principle, which 
states that to prove a property for all bits, it suffices to prove that it holds for bit-0 and 
bit-1. This is a degenerate version of induction, in which there are two base cases and no 
induction step. (Actually the second axiom follows from this induction principle, and so 
could have been stated as a theorem.) 

Then comes the definition of several functions on bits. The function bit-plus is binary 
addition of bits: for example. 

axiom (equal (bit-plus bit-1 bit-1) bit-0) 

says that the result of adding bit-1 to itself is bit-0. 

The function bit-carry gives the bit that is carried when two bits are added. In fact, 
this bit is bit-1 when bit-1 is added to itself: in all other cases, it is bit-0. 

The function bit-and gives the logical conjunction of two bits, regarded as truth values. 
Thus, the conjunction of bit-0 and bit-1 is bit-0, and so on. 

A sequence of theorems about bit addition and other functions is included in the spec- 
ification. The first states that the bit carry function is actually identical to the logical 
conjunction of bits: 

theorem bit-and-carry is (equal (bit-and bl b2) (bit-carry bl b2)) 
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Let us follow the interaction that allows this theorem to be proved. 

First we inform SNARK (by setting its focus to verification) that only theorem proving 
is required, no witness generation. This is done by selecting an item from a menu. We do 
not change the default settings — hyperresolution, paramodulation. recursive-path ordering 
(the term-ordering strategy), etc. for a. verification proof. Menus for SNARK feature selection 
do not exist in pure SNARK: they were implemented as part of the interface, because the 
SPEC WARE user expects analogous interfaces for SNARK and KITE. 

We customize the interface: in particular, we elect to choose which conjectures from the 
specification are to be proven: otherwise, the system will attempt to prove all of them. We 
also elect to chose proof options for each batch of conjectures — this will enable us to decide 
what form of induction principle to use. and to set certain strategic controls if we choose to. 
We indicate how detailed we would like the trace of the proof to appear. 

In setting the SPECWARE focus, we choose to verify the specification BIT. We elect to 
do an induction proof, by induction on bl over {bit-1 ,bit-0} — this is one of two options 
offered. After this, the proof is automatic. In the trace below, which shows the proof of one 
of the two base cases, we show more than the naive user would see — normally, one would 
only learn that the conjecture had been verified. 

.> ;;; Verify conjecture 

;;; fa(b2: Bit, bl: Bit) bit-and(bl, b2) = bit-carry (bl , b2) 

;;; by induction on bl over {bit-1 , bit-0} 

Warning: Setting * PRINT- PRETTY* to NIL. 

gc: done 

The current SNARK option values are 
use-hyperresolution = T 
use-paramodulation = T 
use-factoring = T 

use-term-ordering = : RECURSIVE-PATH 
use-replacement-resolut ion-with-x=x = T 
agenda- length-bef ore- simpl if icat ion- limit = 10000 
agenda-length-limit = 3000 
agenda-ordering-function = ROW-WEIGHT+DEPTH 
pruning- tests = (R0W-WEIGHT-AB0VE-LIMIT-P) 
pruning-tests-bef ore- simpl if icat ion = 

(R0W-WEIGHT-BEF0RE-SIMPLIFICATI0N-AB0VE-LIMIT-P) 
use-clausif ication = T 
use-and-splitt ing = T 


Refutation : 

1: (= ?X ?X) 

assertion 
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3: (OR (= ?X SPEC : : BIT-0) (= ?X SPEC :: BIT- 1) ) 

assertion 

8: (= (SPEC: : BIT-CARRY SPEC::BIT-0 SPEC::BIT-0) SPEC::BIT-0) 

assertion 


10: 

11 : 

14: 

16: 

17: 

18: 

21: 

23: 

24: 

26: 

68: 

102: 

144: 

287: 

288: 


(= (SPEC: : BIT-CARRY SPEC::BIT-1 SPEC::BIT-0) SPEC::BIT-0) 

assertion 

(= (SPEC: : BIT-CARRY SPEC::BIT-1 SPEC::BIT-1) SPEC::BIT-1) 

assertion 

(= (SPEC: :BIT-AND SPEC:: BIT-0 SPEC:: BIT-0) SPEC:: BIT-O) 

assertion 

(= (SPEC: :BIT-AND SPEC::BIT-1 SPEC::BIT-0) SPEC: : BIT-0) 

assertion 

(= (SPEC: :BIT-AND SPEC::BIT-1 SPEC::BIT-1) SPEC: : BIT- 1) 

assertion 

(NOT (= (SPEC: :BIT-AND SPEC :: BIT-1 #: SKI) 

(SPEC: : BIT-CARRY SPEC::BIT-1 #:SK1))) 

"conclusion 

(OR (= ?X SPEC : : BIT-1 ) (= (SPEC :: BIT- AND SPEC :: BIT- 1 ?X) ?X)) 

paramodulate 16 by 3 

(OR (= ?X SPEC : : BIT-1) (= (SPEC : : BIT-AND ?X ?X) ?X)) 

paramodulate 14 by 3 

(OR (= ?X SPEC : : BIT-1) (= (SPEC :: BIT-CARRY SPEC::BIT-1 ?X) ?X)) 

paramodulate 10 by 3 

(OR (= ?X SPEC : : BIT-1) (= (SPEC :: BIT-CARRY ?X ?X) ?X)) 

paramodulate 8 by 3 

(OR (= # : SKI SPEC: :BIT-1) 

(NOT (= # : SKI (SPEC: : BIT-CARRY SPEC::BIT-1 #:SK1)))) 

paramodulate 18 by 21 


(= (SPEC: : BIT-AND ?X ?X) ?X) 

(= (SPEC: : BIT-CARRY ?X ?X) ?X) 
(= # : SKI SPEC: :BIT-1) 

FALSE 


paramodulate 17 by 23 

paramodulate 11 by 26 

hyperresolve 68,24 

rewrite 18 by 1, 144, 
102, 287 


;; Summary of computation: 

; ; 529 formulas have been input or derived (from 43 formulas) . 

; ; 288 (54*/,) were retained. Of these, 

;; 30 (10‘/.) were simplified or subsumed later. 



0 ( 0’/,) were deleted later because the agenda was full, and 
258 (90*/,) are still being kept. 

Run time by activity in seconds 
excluding printing time: 


0.11 

ox 

Resolution 

5.05 

137. 

Paramodulat ion 

0.01 

ox 

Factoring 

20.10 

52'/. 

Forward subsumption 

3.65 

97. 

Backward subsumption 

3.04 

87. 

Forward simplification 

0.12 

07. 

Backward simplification 

0.12 

07. 

Equality ordering 

6.24 

167. 

Other 

38.44 


Total 


Snark result PROOF-FOUND PROOF-FOUND. 

;;; Verified conjecture Bit-And-Carry . 

;;; Verified the 1 conjecture attempted. 

Note that the SPECWARE syntax has been translated into SNARK syntax (via REFINE 
rewriting). Thus the negation of one of the base cases of the SPECWARE conjecture. 

(not (fa (b2 : Bit) 

(equal (bit-and bit-1 b2) 

(bit-carry bit-1 b2)))) 

has been translated into 

(NOT (= (SPEC: :BIT-AND SPEC::BIT-1 #:SK1) 

(SPEC: : BIT-CARRY SPEC: :BIT-1 #:SK1))) 

The SPECWARE equal has been translated into the SNARK = . Specware symbols have 
been prefixed by SPEC: : to avoid name clashes. Also, the quantifier fa has been removed 
and the quantified variable b2 has been replaced by the skolem constant #:SK1, by SNARK 
skolemization, not by the interface. 

This interface has been completed and tested successfully on several SPECWARE theories, 
including the theorems for a specification for bit-vectors, a theory of pictures for the auto- 
mated construction of visualizations of structures, and a formulation of semi-lattice theory 
for JAVA byte-code verification. SRI has also collaborated with Kestrel and NASA person- 
nel on the design of hooks to allow the Meta-Amphion application to invoke SNARK via 
SPECWARE. 


6 Remaining Work 


\\ ith experience we may see ways to improve the SNARK-SPF.CWarF. interfare. Some of these 
problems are as follows: 
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higher-order functions. SPECWARE logic is higher order, while SNA It K is a first-order 
theorem prover. The interface makes no attempt to translate higher-order functions 
and predicates into first-order logic, e.g.. via reification. 

sorts. The interface translates SPECWARE sorts into S.NARK sorts, which is economical. 
However, there is no attempt to deal with such complex SPECWARE sorts as the quo- 
tient. product, or co-product, for which SNARE has no equivalent; presumably, this 
should be done by sort axioms, as in KITP. Also. SPECWARE subsorts are mapped into 
distinct sorts, not into S.NARK subsorts. (In SPECWARE. as in all category theory, an 
element of a subsort is not regarded as an element of its supersort: in SNARE, it is. 

associative-commutative unification. If associative and commutative axioms are pro- 
vided. SNARE will recognize them, remove them from the axiom base, and use associative- 
commutative unification instead. Other than this, there is no mechanism by which a 
user may declare a function or predicate symbol to be associative or commutative. 

witness-finding. SNARE has a witness-finding capability, and a LISP function has been pro- 
vided by which a SPECWARE user may invoke SNARE witness-finding for a SPECWARE 
theorem. However. SPECWARE has no mechanism for referring to a witness within the 
specification itself, and theoretical obstacles exists for introducing such a mechanism, 
unless the theorem establishes uniqueness. 

strategic controls. The SPECWARE user is given no way of introducing a term ordering, 
an agenda-ordering function, or symbol weights for specializing SNARE to a particular 
subject domain: he or she must be happy with the defaults. 

treatment of logic morphisms. \\ hereas the ordinary morphism is a construct supported 
by SPECWARE. the inter-logic morphism is not. Construction of the morphism between 
SPECWARE and SNARE required a lot of ad hoc programming in REFINE. While some 
of this is unavoidable (e.g.. menu design), much of it can be systematized (e.g.. the 
translation between languages). The plan is to introduce the inter-logic morphism into 
SPECWARE as a first-class citizen. 

Interfaces between SPECWARE and other theorem- p rovers, such as PVS. remain to be 
constructed. This effort will be facilitated if the results of the experience of integrating 
SPECWARE and SNARE can inform the development of an implementation of the inter-logic 
morphism within SPECWARE. 



